fix: scaffolded-project path assumptions (#283, #284, #287, #288, #290) - #289

Fixes #283, fixes #284, fixes #287, fixes #288, fixes #290.

Five reports filed against a sm new project scaffold, all one root cause: the framework assumed its own monorepo layout, where a module's directory and assembly are both SimpleModule.<Module>. sm new module scaffolds a bare <Module> for both.

#287 — page bundle 404 on every page load

The client built the bundle URL as _content/SimpleModule.<Module>/…, but an RCL serves its assets under its AssemblyName, so every scaffolded module 404'd before the fallback probe found it.

HtmlFileInertiaPageRenderer now declares the module-name → assembly-name mapping in the page shell, and resolvePage reads it, so the first request goes to the path that actually serves the bundle. Probing stays as a fallback for shells that predate the map, and for an unparseable one.

The same prefix assumption also meant a bare-named module's stylesheet was never linked — BuildModuleCssLinks only matched _content/SimpleModule.*. Module CSS discovery now consults the same mapping.

#283 / #284 — types.ts written into a directory no project owns

extract-ts-types.mjs hardcoded SimpleModule.<Module> as the output project and mkdirSync'd it unconditionally. It now resolves the project directory that actually exists and skips modules with no local source, so:

• a scaffolded module gets its types next to the Pages/ that import them (extract-ts-types.mjs writes types.ts into a SimpleModule.<Module> directory that sm new module never creates #284)
• NuGet-installed modules no longer materialise phantom source trees in a consumer's repo (extract-ts-types.mjs writes types.ts for NuGet-installed modules into the consumer's source tree #283)
• deleting a module no longer resurrects its directory on the next generate:types

Also removes two committed artifacts of the old behaviour — modules/Identity/src/SimpleModule.Identity/ and modules/Core/src/SimpleModule.Core/ — each holding only a generated types.ts and belonging to no project.

#288 — Tailwind never recompiled for new pages

Styles/app.css declares its scan roots as @source directives, but TailwindBuild did not treat them as inputs, so a new page's utility classes were silently never generated. All five declared roots are now inputs: module Pages//Views/, the host ClientApp, the @simplemodule/ui and @simplemodule/client packages, and the staged module bundles — with @(TailwindExtraSourceFiles) as an extension point for hosts that add @source directives of their own.

template/SimpleModule.Host/wwwroot/css/app.css is no longer tracked. .gitignore's "Tailwind CSS build output" rule already excluded it (allowlisting only favicon.svg, index.html, error.html); it had been force-added. With the input set widened, the target now reruns on nearly every frontend edit, so the stale committed copy was being rewritten constantly and produced a ~5,000-line spurious diff on every build. CI and Docker each compile the CSS themselves and the Host is IsPackable=false, so nothing depended on it.

#290 — scaffolded hosts never scanned packaged modules' bundles

HostTemplates.AppCss() stripped the @source "./_scan/" line, so a scaffolded host staged every packaged module's built .pages.js into Styles/_scan/ and then never scanned it — utility classes appearing only in a packaged module rendered unstyled. The path is relative to Styles/, so the same line is correct in both layouts.

This was originally deferred out of a concern that Tailwind would fail on a missing directory in a fresh scaffold. It does not — v4 skips absent @source roots without error (verified directly), and CollectModuleAssets creates the folder before TailwindBuild runs regardless. The monorepo-only docs/design-system root is now stripped instead, since a scaffold has no such directory.

Verification

• Tailwind build does not re-run when module Pages change, so new utility classes silently never compile #288 — reproduced on unmodified main: added bg-lime-700 to a module page, rebuilt, class absent from app.css. With the fix, bg-fuchsia-800 compiles in.
• extract-ts-types.mjs writes types.ts for NuGet-installed modules into the consumer's source tree #283/extract-ts-types.mjs writes types.ts into a SimpleModule.<Module> directory that sm new module never creates #284 — ran the script against a fixture with all three shapes: src/<Name> (scaffold), src/SimpleModule.<Name> (framework), and a module with no source. Writes into the first two, skips and creates nothing for the third. Re-running against this repo produces zero changes to any existing types.ts.
• Page bundle requested as _content/SimpleModule.<Module>/ but the RCL serves it at _content/<Module>/ — 404 on every page load #287 — against a running host, every route fetches exactly one bundle at its declared assembly name (HTTP 200) on both full page loads and client-side SPA navigation, with zero failed requests and zero console errors. A fabricated assembly name still 404s, so those 200s are meaningful.
• Scaffolded host strips @source "./_scan/", so packaged modules' Tailwind classes are never compiled #290 — HostTemplatesAppCssTests fails when the strip is restored and passes without it.

Tests added

• InertiaEndpoint_DeclaresAssemblyNameThatServesEachModuleBundle — asserts every module with pages is declared and every declared value is a real loaded assembly.
• tests/e2e/tests/smoke/module-bundles.spec.ts — end-to-end: for each module route the shell must declare an assembly for that page's module and the browser must fetch exactly that bundle, once, with a 200. Expectations are derived from the shell's own Inertia component name and assembly map rather than a hardcoded route table. Confirmed it fails (5/5 route cases) when the map is emptied. Also asserts Tailwind utilities survive compilation, with an unused control class proving the check discriminates.
• HostTemplatesAppCssTests — guards the retained _scan source and the scaffold path rewrites. SimpleModule.Cli.Tests sets IsTestProject=false, so dotnet test skipped it entirely and these would have guarded nothing; the build job now runs that class explicitly.

Local CI

Lint/format, validate-pages, validate:i18n, framework-scope, typecheck 15/15, dotnet build 0 warnings / 0 errors under TreatWarningsAsErrors, full suite green (20 assemblies, 1,309 tests, 0 failures), CLI template tests 4/4, e2e smoke suite 72/72.

Out of scope

Review surfaced issues in code already on main that this PR does not touch, left alone deliberately rather than bundled into a path-fix change:

• Default admin credentials reachable in Production. auth.show_test_accounts has DefaultValue = "true" with no environment gate and LoginEndpoint falls back to it, while Login.tsx hardcodes admin@simplemodule.dev / Admin123! and the seeder now always applies that default (fix: shutdown-noise in background services + seed defaults so the app starts out of the box #279). A Production container with no seed config renders a working "Login as Admin" button. Fixing it reverses part of the deliberate out-of-box decision, so it needs its own change.
• ProgressFlushService re-reads moduleOptions.Value in the shutdown drain instead of the captured opts.
• IsLocalOrTest's doc comment still describes fail-closed guards that now only warn.